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Abstract 

The seaport of Gioia Tauro is the largest transshipment terminal of the Mediterranean 
coast. A crucial management task for the companies operating in the seaport is team 
building: the problem of properly allocating the available personnel for serving the incom- 
ing ships. Teams have to be carefully arranged in order to meet several constraints, such 
as allocation of the employees with the appropriate skills, fair distribution of the working 
load, and turnover of the heavy /dangerous roles. This makes team building a hard and 
expensive task requiring several hours per day of manual preparation. 

In this paper we present a system based on Answer Set Programming (ASP) for the 
automatic generation of the teams of employees in the seaport of Gioia Tauro. The system 
is currently exploited in the Gioia Tauro seaport by ICO BLG, a company specialized in 
automobile logistics. 

KEYWORDS: Answer Set Programming, Declarative Problem Solving, Knowledge Man- 
agement, Workforce Management, Artificial Intelligence. 



1 Introduction 

In the last few years, the need for knowledge-based technologies has emerged in 
several application areas. Industries are now looking for semantic instruments for 
knowledge management enabling complex domain-knowledge modeling and real- 
world problem solving. We report on a recent successful industrial application wc de- 
veloped in the area of Knowledge Management (KM) , which is based on Answer Set 
Programming (ASP) ([Gelfond a nd Lifschitz 1991). ASP is a fully-declarative lan- 
guage for Knowledge Representation and Reasoning (KRR), which has been devel- 
oped in the field of logic programming and nonmonotonic reasoning. ASP has been 
already exploited for solving complex knowledge-based problems arising in Artificial 
Intelligence (jBaral and Gelfond 200fllBalduccini et al. 2001||Baral and Uyan 2001[ 
IFriedrich and Ivanchenko 2008| iFranconi et al. 2001)IGebser et al. 20071 |Nogueira et al. 2001] 
as well as in Information Integration (jLeone et al. 2005]) . and other areas of Knowl- 
edge Management (jBaral 2003: Bardadym 1996; Grass o et al. 2009] . In recent years, 
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the high knowledge-modeling power of this language has been made available to 
users, who need to represent and manipulate complex knowledge, by the develop- 
ment of some efficient ASP systems, such as DLV (jLeone et al. 2006)) . 

In this paper, we present a new system, based on the ASP solver DLV, which 
is currently exploited by the ICO BLG company in the international seaport of 
Gioia Tauro. The system allows for the automatic generation of teams of em- 
ployees. Roughly, the problem we deal with is a workforce management prob- 
lem (|Naveh et al. 2007|lErnst et al. 2004||Tien and Kamiyama 1982|ILau 1996(|Yang 1996] ), 



which amounts to computing a suitable allocation of the available personnel of the 
seaport such that cargo ships mooring in the port are properly handled. To accom- 
plish this task several constraints have to be satisfied. An appropriate number of 
employees, providing several different skills, is required depending on the size and 
the load of cargo ships. Moreover, the way an employee is selected and the specific 
role she will play in the team (each employee is able to cover several roles according 
to her skills) are subject to many conditions (e.g., fair distribution of the working 
load, turnover of the heavy /dangerous roles, etc.). Up to now, the management of 
ICO BLG has been obliged to dedicate several hours per day to the difficult and 
delicate task of allocating teams of employees to incoming ships. Indeed, a bad 
allocation might cause delays or violations of the contract with shipping compa- 
nies, with consequent pecuniary sanctions. Moreover, an unfair distribution of the 
workload can lead to problems with human resources management, ranging from: 
(i) the unavailability of crucial human resources -when highly-skilled employees are 
not allocated in the best way- (ii) to the loss of employee happiness -resulting from 
an unfair distribution of heavy/dangerous roles- that can directly affect production 
and performance. Thus, team building is definitively a crucial and difficult man- 
agement task for ICO BLG, for which we developed an effective software solution. 

The system described in this paper can either build new teams or automatically 
complete a partial allocation when the user manually pre-assigns some key employ- 
ees. Moreover, it is able to verify whether a manually-composed team satisfies all 
the requirements, or not. It might be the case that there is no team satisfying all 
requirements, or that a team violates some condition due to user pre-assignmcnts. 
In these cases, the system provides a suitable explanation of violations for allowing 
the user to take corrective actions. Further, the system can also be used by the 
managers of the company for performing simulations in order to estimate impor- 
tant financial aspects. For instance, by computing ahead the whole shift scheduling 
for the next month, it is possible to evaluate how much overtime will be needed 
and allow/deny leave requests. Notably, in this application, the domain knowledge 
is dcclaratively modeled by exploiting ASP and implemented by using the ASP sys- 
tem DLV. Desired allocations are computed by means of a set of suitably defined 
ASP programs. 

The contribution of this paper is twofold: firstly, we report on a successful industrially- 
developed KM system which is currently employed in the important port of Gioia 
Tauro (the system is commercially-distributed by EXEURA s.r.L, a spin-off com- 
pany of the University of Calabria); secondly, we describe how ASP can be prof- 
itably exploited for solving a specific KM problem. The work represents a practical 
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demonstration that ASP is well-suited for developing effective real-world KM sys- 
tems. 

In the literature there is a number of systems and methods for solving various vari- 
ants of the workforce management problem (jNaveh et al. 20071 lErnst et al. 20041 
Tien and Kamiyama 1982] ILau 19961 |Yang 1996[ ). The available solut ons can be 



classified in two main categories: (i) ad-hoc algorithms, and (ii) generic methods. 
The first category has the drawback of producing solutions that are very specific 
which cannot be easily adapted for solving a different variants of the same prob- 
lem; in practice they are employed for solving problems with unique features (see 



e.g., Burke and Soubeiga Hultberg and Cardoso 1997). Conversely, our approach 



belongs to the second category where, historically, both Operational Research and 
Artificial Intelligence methods (such as Constraint Programming, Fuzzy logic, Ge- 
netic Algorithms, and Local Search) were employed (see e.g., INaveh et al. 20071 
lErnst et al. 2004||Tien and Kamiyama 1982|lLau 1996||Yang 1996|lCerulli et al. 1992| 



ILesaint et al. 20031lEiFzen et al. 2004llDechter 2004"llGresh et al. 2007|IBechtold et al. 1991) 
lAlfares 20021 IBillionnet 1999"llSun et al. 1998|lATckelin and Dowsland 2000(IWren and Wren 1995| 
IChiu et al. 20051 IRossi 20"00HAl-Yakoob and Sherali 200711 Alba and Chicano~2T)07l) I 1 ! 
The solutions presented in this paper also demonstrate that ASP can be exploited 
on a par with other Al techniques for developing effective workforce management 
systems. The distinctive features of our approach are: 

• the distinction of individual employee^! by taking into account (i) specific 
employee-skills, (ii) current allocation history, and (iii) temporary unavail- 
ability (owing to illness or special permission); 

• the satisfaction of practically-relevant cooperative work requirements, like the 
turnover of heavy /dangerous roles; and "double shift" allocations (where the 
same workers have to be employed in two adjacent shifts while respecting 
constraints); 

• system interactivity: the user can manually modify the provided solutions, 
since the system is able to deal with partial allocations and provide explana- 
tions when constraints are violated by manual modification; 

• high flexibility and maintainability: the system exploits a flexible, and easy- 
to-maintain core logic; 

• user friendly graphical interface that makes the use of the underlying tech- 
nologies transparent to the user. 

An important lesson we learned in this project is that the high expressiveness of 
ASP language, which allows us to obtain an executable specification, is an impor- 
tant advantage that can lead to prefer ASP over other approaches in applications 
of this kind. Indeed, the expressiveness of ASP and its purely declarative nature 



1 For an in-depth comparison/characterization of solv ed problems and adopted methods 
we refer the reader to the following survey papers jNaveh et al. 20071 lErnst et al. 20041 
|Tien and Kamiyama 1982) ILau 19961 |Yang 1996| l. 

2 A feature missing in most of the existent approaches, as observed by|Naveh et al. (2007||. 
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allowed us to refine and fine-tune both problem specifications and encodings to- 
gether, while interacting with the stakeholders of the port. We could easily simu- 
late specification changes and immediately show their effects to the customers. The 
possibility of modifying (simply by editing a text file) a complex reasoning task 
(e.g., by adding new constraints or by changing existing ones) in a few minutes and 
testing it "on-site" together with the customer is a great advantage of our approach, 
it was highly appreciated by our customers, and constituted a key factor for the 
success of our application. We believe that such an advantage could be exploited in 
several contexts. 

The result is a system that perfectly matches the requirements of the customer 
by allowing both fast planning and fair employee allocation, while respecting the 
constraints. The management of ICO BLG can now produce an admissible person- 
nel allocation in a few minutes: they spend less time and obtain a more effective 
planning of the resources. 

The remainder of this paper is organized as follows: in the next section we give an 
overview of ASP; Section [3] provides a specification of the team building problem; 
while in Section |4] we give an ASP encoding of the problem; Section [5] describes 
the architecture of the system and its functionalities; Section |6] reports on the 
performances of the system on real- world data; Section [7] concludes the paper. 



2 Answer Set Programming 

In this section we recall syntax and semantics of Answer Set Programming (ASP). 
More specifically, we present an enriched language allowing for using set-oriented 
functions, also known as aggregate functions. For further background on the stan- 
dard ASP language we refer to Baral (2003 ) and Gelfond and Leone (2002 1 . For 
details on ASP with aggregate functions, instead, we refer to Faber et al. (2004) 
and|Lee and Meng (2009|. 



2. 1 Syntax 

We assume sets of variables, constants, and predicates to be given. Similar to Prolog, 
we assume variables to be strings starting with uppercase letters and constants to 
be non-negative integers or strings starting with lowercase letters. Predicates are 
strings starting with lowercase letters. An arity (non-negative integer) is associated 
with each predicate. Moreover, the language allows for using built-in predicates 
(i.e., predicates with a fixed meaning) for the common arithmetic operations (i.e., 
=, <, <, >, >, +, etc.; usually written in infix notation). 

Standard Atoms. A term is either a variable or a constant. A standard atom is an 

expression p(ti tfe), where p is a predicate of arity k and ti tfe are terms. 

If ti , . . . ,tfc are constants, p(ti tfe) is a ground standard atom. 

Set Terms. A set term is cither a symbolic set or a ground set. A symbolic set 
is a pair {Terms : Conj}, where Terms is a list of terms (variables or con- 
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stants) and Conj is a conjunction of standard atoms. Intuitively, a set term X: 
a(X,Y), b(Y) stands for the set of X-values making the conjunction a(X,Y), b(Y) 
true, namely {X | 3 Y s.t. a(X,Y) , b(Y) is true}. A ground set is a set of pairs of the 
form (consts : conj), where consts is a list of constants and conj is a conjunction of 
ground standard atoms. 

Aggregate Functions. An aggregate function is of the form f(S), where S is a set 
term and / is an aggregate function symbol. Intuitively, an aggregate function can 
be thought of as a (possibly partial) function, mapping multisets of constants to con- 
stants. Hereinafter, we will adopt the notation of the DLV system (jLeone et al. 2006]) 
for representing aggregate functions: 

• #min (minimal term, undefined for empty set); 

• #max (maximal term, undefined for empty set); 

• #count (number of terms); 

• #sum (sum of integers). 

Aggregate Atoms and Literals. An aggregate atom is a structure of the form f(S) 
T, where f(S) is an aggregate function, e {<, <, >, >, =, 7^} is a comparison 
operator, and T is a term (a variable or a constant). If T is a constant and S is 
a ground set term, f(S) T is a ground aggregate atom. A literal is either (i) a 
standard atom, or (ii) a standard atom preceded by the negation as failure symbol 
not, or (hi) an aggregate atom. 

Programs. A rule r is a construct of the form 

ai V - V a„ :- 4 ...,!,„■ 

where ct\, . . . , a n are standard atoms, £\, . . . , £ m are literals, n > 1 and m > 0. 
The disjunction osi V • • ■ V a n is referred to as the head of r, while the conjunction 
£%, . . . , £ m is the body of r. We denote by H(r) the set of head atoms and by B{r) 
the set of body literals. If H{r) and all the literals in B{r) are ground, r is a ground 
rule. A ground rule r is a fact if both B{r) — and \H(r)\ — 1. A program V is a 
set of rules; if all rules in T 3 are ground, P is a ground program. 

Safety. A focaZ variable of a rule r is a variable appearing solely in set terms of 
r; a variable of r that is not local is global. A rule r is sa/e if both the following 
conditions hold: (i) each global variable appears in some positive standard literal of 
B(r); (ii) each local variable appearing in a set term {Terms : Conj} also appears 
in Conj. A program is safe if all its rules are safe. In the following, we assume that 
programs are safe. 

Example 1 

Consider the following rules: 

c(X) :- q(X,Y,V), #max{Z: a(Z) , b(Z,V)} > Y. 
c(X) :- q(X,Y,V), #sum{Z: a(X) , b(X,S)} > Y. 
c(X) :- q(X,Y,V), #min{Z: a(Z) , b(Z,V)} > T. 
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The first rule is safe, while the second is not because the local variable Z violates 
condition (ii). The third rule is not safe because the global variable T violates 
condition (i). 

2.2 Answer Set Semantics 

Semantics of an ASP program is given by the set of its stable models, defined in 
this section. 

Universe and Base. Given an ASP program V, the universe of V , denoted by Up, 
is the set of constants appearing in Va The base of V, denoted by Bp, is the set 
of standard atoms constructive from predicates of V with constants in Up . 

Instantiation. A substitution is a mapping from a set of variables to U-p. Given a 
substitution a and an ASP object obj (atom, rule, set term, etc.), we denote by 
obj a the object obtained by replacing each variable X in obj by er(x). A substitution 
from the set of global variables of a rule r (to Up) is a global substitution for r; 
a substitution from the set of local variables of a set term S (to Up) is a local 
substitution for S. Given a set term without global variables S = {Terms : Conj}, 
the instantiation of S is the following ground set term: 

inst(S) = {(Terms a : Conj a) \ a is a local substitution for S}. 

A ground instance of a rule r is obtained in two steps: first, a global substitution a 
for r is applied; then, every set term S in ra is replaced by its instantiation inst(S). 
The instantiation Ground(V) of a program V is the set of instances of all rules in 
V. 

Example 2 

Consider the following program V\ : 

a(l) v b(2,2) . 
a(2) v b(2,l) • 

c(X) :- a(X), #sum{Y: b(X,Y)} > 2. 
The instantiation Ground{V\) of V\ is the following program: 

a(l) v b(2,2) . 

a(2) v b(2,l) . 

c(l) :- a(l), #sum{(l: b(l,D), (2: b(l,2))} > 2. 

c(2) :- a(2), #sum{(l: b(2,l)>, (2: b(2,2))} > 2. | 

Interpretations. An interpretation I for an ASP program V is a subset of Bp. A 
standard ground atom a is true with respect to I if a G /; otherwise, a is false with 
respect to I. A negative standard ground literal not a is true with respect to I if 
a £ I) otherwise, not a is true with respect to /. 

An interpretation I also provides a meaning to set terms, aggregate functions 

3 If a program V has no constants, an arbitrary constant symbols § is introduced. 
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and aggregate literals, namely a multiset, a value, and a truth value, respectively. 
The evaluation I(S) of a set term S with respect to / is the multiset I(S) defined 
as follows: Let S 1 = {(ti, ...,ifc) | (ti, •••,ifc : Conj) G S and all the atoms in Conj 
are true with respect to /}; then, I(S) is the multiset obtained as the projection of 
the tuples of Si on their first constant, that is, I(S) = [ti \ (t 1: ... 7 t n ) 6 S 1 ]. The 
evaluation I(f(S)) of an aggregate function f(S) with respect to / is the result 
of the application of / on I(S). If the multiset I(S) is not in the domain of /, 
I(f(S)) = _L (where _L is a fixed symbol not occurring in V). A ground aggregate 
atom f(S) k is true with respect to / if both I(f(S)) ^ _L and I(f(S)) k hold; 
otherwise, f(S) k is false. 

Models. Given an interpretation /, a rule r is satisfied with respect to I if some head 
atom is true with respect to / whenever all body literals are true with respect to /. 
An interpretation M is a model of an ASP program V if all the rules r 6 Ground^) 
are satisfied with respect to M . A model M for V is (subset) minimal if no model 
N for V exists such that N C 7U0 

Answer Sets. We now recall the generalization of the Gelfond-Lifschitz transfor- 



mation and answer sets for programs with aggregates from Faber et al. (2004 1: Let 
V be a ground program, / be an interpretation, and V 1 denote the transformed 
program obtained from V by deleting all rules in which a body literal is false with 
respect to /. An interpretation M is an answer set of the program V if it is a 
minimal model of Ground(V) M . 

Example 3 

Consider two interpretations I\ = {a(0)} and I2 = {b(0)} for the next programs: 

Vi = {a(0) :- #count{X: b(X)} > 0.} 
V 3 = {a(0) :- #count{X: b(X)} < 0.} 

Hence, we obtain the following transformed programs: 

Ground^) 11 = 

GroundCP-z)' 2 = Ground^) = {a(0) :- #count{(0: b(0)}} > 0.} 
Ground^)' 1 = GroW(P 3 ) = {a(0) :- #count{(0: b(0)}} < 0.} 

GroundiViY 2 = 

Hence, neither I\ nor I2 are answer sets of Vi , while I\ is an answer set of V3 
because is not a model of Ground(V3) 11 . On the other hand, I2 is not an answer 
set of V3 because is a model of Ground(V3) 12 . 

Note that the syntax of the language does not explicitly allow rules without head 
atoms, called constraints. However, constraints can be simulated by using a new 
symbol and negation. For example, a constraint of the form :— £1, . . . , £ m can 
be replaced by a rule of the form co :— l\, . . . , £ m , not co, where co is a symbol 
not occurring in V . 

4 Note that an answer set M of "P is also a model of V ■ Indeed, Ground{V') M C Ground(P) and 
rules in Ground(V) \ Ground(V) M are satisfied with respect to M by definition of reduct. 
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3 Problem Motivation and Specification 

The seaport of Gioia TaurcEl is the largest transshipment terminal of the Mediter- 
ranean coast. Most of the transported goods reach and leave this port by ship, 
and only a minimal part of them (about 5%) is transferred by train or truck. His- 
torically, container transshipment has been the main activity of the port (related 
problems were the subject of extensive research; see e.g-. IVacca et al. 2007)1 . while 
recently Gioia Tauro has become also an automobile hub. Automobile logistics is 
carried out by the ICO BLG companjffl on an area of 320,000 m 2 corresponding to 
a warehouse capacity for about 15,000 vehicles. In the last few years, cargo traf- 
fic has increased impressively in Gioia Tauro: every day several vessels of different 
capacities moor in the port carrying their load of new cars and trucks. The vehi- 
cles they transport might have to be handled, warehoused, processed (if technically 
necessary) and finally delivered to their final destination. Depending on the specific 
processing needs, the load of a mooring ship might be subject to different activities, 
each of which requires the allocation of a number of specifically-skilled employees. 
For instance, a ship might be partially or fully loaded/unloaded, and transported 
vehicles identified, quality-checked and moved to/from the port yard. Moreover, 
cars (possibly-damaged during transportation) might undergo an additional repair- 
ing process. The port is, in fact, equipped with a centre able to repair both minor 
damage to car bodywork and to perform pre-delivery services such as polishing, 
washing, battery testing, etc. 

The time required for processing ships is set up by contract. For this reason, 
a critical management goal is to serve arriving boats promptly because any de- 
lay might cause financial penalties to the company. In order to accomplish that 
task, several teams of employees have to be arranged and scheduled to work si- 
multaneously on these ships. The selection of the employees and the assignment of 
roles is subject to many conditions. Some constraints are imposed by the employees 
skills and availability, other by contract (in general identified as legal conditions). 
For example, each team usually includes at least one "quality-checker" , and en- 
rolls a sufficient number of drivers for loading/unloading cars in time. Moreover, 
each employee cannot work more than 36 hours (plus max 12 hours of overtime) per 
week and, importantly, heavy /dangerous roles must be turned over. Note that some 
tasks require that employees work in "bad conditions" ; for instance, the employ- 
ees performing operations in the hold (while cars are driven in/out of a ship) arc 
persistently exposed to a high concentration of pollution. Hence, daily assignments 
to such heavy roles must be turned over among the personnel, so that hard and 
easy tasks are shared among employees. Moreover, a fair distribution of work has 
to be obtained by ensuring that all the employees are enrolled for about the same 
number of hours in a week. In this way, both the best possible working conditions 
for the employees and the processing of all incoming boats are guaranteed. 

Data regarding arriving/departing ships, such as date and time, number and kind 



See |http:/ /www . portodigioiat auro ■ it | 

ICO BLG is a subsidiary of the BLG Logistics Group — [httpT// www. blg.de 
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of transported vehicles, are usually known by the managers (at least) one day in 
advance. Given these data, the management easily identifies the team composition 
characteristics needed for processing a given ship (i.e., how many employees are 
needed, what skills the workers must have, how the working time is divided in 
shifts, etc.). According to ICO BLG terminology, we say that a meta-plan is a 
specification of the needed skills and number of employees for one shift. (A meta- 
plan usually refers to a single ship.) However, the subsequent task of assigning the 
available employees to shifts and roles (remember that each employee is able to 
cover several roles according to her skills) , in such a way that all the requirements 
are satisfied, is definitively the hardest part of the whole rostering process. 

The ICO BLG managers were used to find out a "hand-made" solution. Of course, 
this technique was far from being effective and efficient. Indeed, arranging teams re- 
quired many hours, often resulting in solutions not fulfilling several constraints. The 
impossibility of allocating teams to incoming ships might cause delays and viola- 
tions of the contract with employees or with shipping companies. As a consequence, 
team building is definitively a crucial management task for ICO BLG. 

In the following, all the requirements to be fulfilled are specified in more detail. 

3.1 Team Requirements and Available Personnel 

Information regarding mooring ships, such as arrival and departure time as well 
as their processing needs (load/unload, size of the load, etc.), is known one day in 
advance, and the rostering process is always carried out by considering one day at 
time. Moreover, working time of a day is divided in shifts lasting 6-12 hours each. 
Given this information, the managers can easily produce a specification of the 
resources needed during the working shifts for dealing with the incoming ships. In 
particular, the following information is specified: the shift data (date-time identifier 
and duration), the set of skills to be covered, and the number of needed employees 
per skill. This is the main input of our team building system because the goal is 
to select the right workers among those which are available for fulfilling resource 
requests. However, the availability of a specific employee for a given shift depends 
on several conditions, some of which are stated by the employees contract, some by 
other circumstances. 

Concerning legal requirements, we already mentioned that an employee cannot 
exceeds a certain amount of working hours (including overtime) per day and per 
week. These values are given as input parameters within our system, together with 
the allocation history recording the number of elapsed working hours for each em- 
ployee. A further condition imposed by the contract regards night-shifts. It states 
that an employee who has worked during a night-shift must have a mandatory rest 
time before being allocated once more. In addition, an employee can be assigned 
to a single vessel in a given shift, but she can be moved to a different vessel in 
a subsequent shift. An employee cannot change role in a shift, but she can play 
different roles in different shifts. Finally, an employee is not available if either she 
is in vacation, or a specific management decision requires that she must not be a 
member of the team. 
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3.2 Turnover and Fairness Requirements 

As previously pointed out, to obtain the best possible working conditions for the 
employees, heavy /dangerous roles have to be turned over. More in detail, a "round- 
robin like" turnover policy should be applied for avoiding that the same group of 
employees is mostly allocated to heavy /dangerous roles. Moreover, a fair distribu- 
tion of the workload has to be ensured in such a way that all the employees have 
to be allocated for about the same amount of weekly hours. This requirement con- 
cerns the way the workload is spread over employees within a week. As an example, 
suppose that the workload expected for a given week is relatively low. In this case, 
the possible solutions range from the exploitation of the same few employees (pos- 
sibly up to their weekly limit of hours) and the distribution of the few shifts to 
distinct available employees. Clearly, the last scenario is the fairest and, in general, 
it should be avoided that a group of employees works less (or is unemployed) in a 
week, whereas some other group is overloaded. Basically, the larger admissible gap 
of worked hours among employees has to be maintained below a threshold (which 
can be set as a parameter in our system) of usually 8 hours. 

3.3 Crucial Roles 

The employees of ICO BLG, in general, can play different roles in a team, depending 
on their skills. For instance, the same employee can be enrolled in a team as a driver 
(her role is to drive cars in/out of the boats) or as a quality-checker, in case she 
is skilled on both activities. Clearly, there are a few employees skilled in critical 
roles (such as quality-checkers), while almost all employees are skilled for easy roles 
(e.g., all employees are drivers). If employees skilled in critical roles are not employed 
carefully, it might be the case that a team satisfying all the requirements cannot 
be built. Indeed, if these few employees are assigned to other (more common) roles 
during the first days of the week, it might happen that they become unavailable on 
the last days of the week (e.g., they may have already reached 36 working hours). 
In order to avoid these disadvantageous situations, employees having crucial roles 
have to be preserved if possible. 

3.4 Double Shift 

A very specific requirement of our team building problem is the possibility of speci- 
fying double shifts. So far, we have just considered (simple) shifts, where employees 
starts and finish working performing the same role. Instead, a double shift can be 
thought of as two consecutive (simple) shifts where the same employees are assigned 
to possibly different roles0More in detail, let n\ and n-i be the number of employees 
required for two shift s\ and S2, respectively; a double shift has the following prop- 
erty: if S2 does not require a higher number of workers than s\ (i.e., n<x < n\), then 
only employees already working in s\ have to be used in S2] otherwise > n\) 1 

7 Note that this requirement cannot be enforced by considering single shifts only. 
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all the employees working in si have to be allocated in S2 and the team has to 
be (possibly) augmented by taking additional employees. Moreover, when moving 
from si to S2, roles must be turned over with respect to the assignment of s\. 

4 ASP-based Encoding 

This section describes the ASP program which solves the team building problem 
specified in the previous section. First, the input data is described; then, the ASP 
rules computing teams of employees are described. 

4- 1 Input Specification 

The input of the process is specified by means of the predicates described in this 
section. The association among employees and skills is expressed by instances of 
has Skill (employee, skill). Instances of absent (employee, shift) are used for storing 
information regarding employees being not available on a given shift because not 
present (e.g., for day off, for disciplinary decision, or for resting after a night-shift). 
In addition, instances of manually Excluded (employee, shift) are used for modeling 
employees who do not have to be considered according to some management deci- 
sion (to allow manual intervention on the allocation of specific employees). Shifts 
are modeled by instances of shift (shiftld, duration), reporting the duration of each 
shift. Moreover, the temporal sequence of shifts is represented by instances of pre- 
vious Shift (shift, shift' ), where shift' immediately precede shift. Resource require- 
ments are represented by instances of neededEmployees (shift, skill, n), reporting 
the number n of needed employees for each shift and skill. 

Statistics concerning past allocations are modeled by instances of workedWeekly- 
Hours(employee, hours) and workedDaily Hours (employee, hours), modeling worked 
hours for each employee up to the current allocation. Similarly, instances of worked- 
WeekOvertimeHours(employee, hours) are used for modeling the count of overtime 
for each employee up to the current allocation. Instances of these predicates are 
produced by querying an internal database that is not described here to simplify 
the presentation. Few additional parameters of the process are given by means of 
the following predicates: an instance of daily Hours (hours) for specifying the maxi- 
mum numbers of working hours allowed per day; an instance of weekHours (hours) 
for setting the maximum numbers of working hours allowed per week; an instance 
of weekOvertime(hours) specifying how many overtime hours per week an employee 
is allowed to work. 

The predicates described up to now constitute the input of the subprogram re- 
ported in Section 14.21 and used for effectively produce all candidate solutions for 
the team building problem. The input in enriched by predicates allowing for dis- 
carding candidate solutions violating preference requirements on heavy/dangerous 
(Section l4.3|) or crucial roles (Section |4.4|) . In particular, heavy/dangerous roles are 
specified by instances of heavyRolef skill) and, for each employee and skill, the last 
allocation date of that employee on that skill is given by an instance of lastAllo- 
cation( employee, skill, lastTime). Moreover, the maximum admissible difference of 
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working hours among all the employees is given by an instance of fairGap (hours). 
Concerning crucial skills, they are identified by instances of crucialRole( skill). More- 
over, the input contains an instance of hasCrucial(employee, n) for each employee, 
specifying the number n of her crucial skills. 

Finally, double shifts are modeled by instances of isDouble(shifti, shifts), where 
shifti and shifts are consecutive (simple) shifts, and the number of employees re- 
quired by shifti is less than or equal to the one required by shift2- These facts are 
used by the subprogram reported in Section [4.51 

4-2 Team Requirements and Available Personnel 

The following rule identifies the set of employees who can be assigned to a specific 
role in each shift: 

canBeAssigned(Em,Sh,Sk) :- hasSkill(Em,Sk) , neededEmployees(Sh,Sk,_) , 
not absent (Em, Sh) , not manuallyExcluded(Em,Sh) , 
not exceedTimeLimit (Em, Sh) . 

In detail, an employee Em can be assigned to a shift Sh for a role Sk if the following 
conditions are satisfied: (i) she has the skill Sk; (ii) Sh needs employees with skill Sk; 
(iii) she is not absent (iv) she is not excluded by some managers decision; and (v) 
she does not exceed time limits. Predicate exceedTimeLimit is intentionally defined 
as follows: 

exceedTimeLimit (Em, Sh) :- shift(Sh,D), 

workedWeeklyHours(Em,Wh) , weekHours (Hmax) , D + Wh > Hmax. 

exceedTimeLimit (Em, Sh) :- shift (Sh, D) , dailyHours (Hmax) , 
workedDailyHours (Em.Wh) , D + Wh > Hmax. 

exceedTimeLimit (Em, Sh) :- shift(Sh,D), weekOvertime (Hmax) , 
workedWeekOvertimeHours(Em,Wh) , D + Wh > Hmax. 

In particular, the first rule can be read as follows: "if a shift Sh has duration D and, 
for a given employee Em, the sum of D with Wh (the hours worked by Em up to Sh) 
is greater than Hmax (the maximum allowed hours in a week), then Em exceeds the 
time limit when associated to Sh" . The remaining two rules can be interpreted in a 
similar way if daily worked hours and overtime are considered instead. 

Next, according to the guess&check programming methodology (jEiter et al. 2000[ 
ILeone et al. 2006]) . the following disjunctive rule guesses the selection of employees 
that can be assigned to the shifts in the appropriate roles: 

assign (Em, Sh,Sk) v nAssign(Em,Sh,Sk) :- canBeAssigned(Em,Sh,Sk) . 

This rule can be read as follows: "if an employee Em matches the skill requirements 
for a shift Sh, then Em can be assigned to Sh, or not" . Assignments violating team 
requirements are filtered out by the following constraints: 

:- neededEmployees(Sh,Sk,EmpNum) , #count{Em: assign (Em, Sh,Sk)} 7^ EmpNum. 
:- assign(Em,Sh,Ski) , assign (Em, Sh, Sk 2 ) , Ski / Sk 2 . 
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:- assign (Em, Shi ,_) , assign(Em, Shn , _) , Shi 7^ Sh 2 . 



(*) 



In particular, the first constraint discards assignments with a wrong number of 
employees per required skill (in other words, an assignment is discarded if the total 
count of employees assigned to a skill does not match requirements). On the other 
hand, the second and third constraints avoid that the same employee covers two 
roles or two shifts, respectively!! 




A careful assignment to heavy /dangerous roles is probably one of the most impor- 
tant requirements for ensuring the best possible working conditions to employees. 
We achieved this behavior by employing the following rule: 

pref ByTurnover (Emi ,Em2 ,Sh,Sk) :- heavyRole (Sk) , 

canBeAssigned(Emi ,Sh,Sk) , canBeAssigned(Em2 ,Sh,Sk) , 

lastAllocation(Emi ,Sk,Datei) , lastAllocation(Em2 ,Sk,Date2) , Datei < Date2 . 

According to this rule, if two employees Emi and Em2 are both skilled on a heavy role 
Sk, and Em2 has performed Sk more recently than Emi, then Emi is preferred to Em2. 
Therefore, for each shift and heavy role, predicate prefByTurnover states a priority 
ordering among employees, and the following constraint implements rotation of 
roles by forbidding assignments whenever turnover preferences are not respected: 

:- pr ef ByTurnover (Emi ,Em2 ,Sh,Sk) , assign (Em2 ,Sh,Sk) , not assign (Emi ,Sh,Sk) . 

In particular, for a given shift, the assignment of an employee Em2 on a role Sk is 
forbidden when there is an unassigned employee Emi having higher priority than Em2 
on Sk. Clearly, this implies that admissible solutions are only those that actually 
ensure an effective turnover, applying a "round-robin" policy among workers. Fol- 
lowing a similar approach, we can impose the fairness requirement for spreading the 
workload among employees. The next rule sets allocation priorities among available 
workers: 

pref ByFairness (Emi ,Em2 ,Sh,Sk) :- f airGap (MaxGap) , 

workedWeeklyHours(Emi ,Whi) , workedWeeklyHours (Em2 ,Wh2) , 
canBeAssigned(Emi ,Sh,Sk) , canBeAssigned(Em2 ,Sh,Sk) , Whi + MaxGap < W12 . 

In detail, if the gap on weekly worked hours between employees Em 2 and Emi exceeds 
the maximum amount allowed, then Emi has higher priority than Em 2 - 
Solutions violating fairness preferences are discarded by the constraint 

:- pref ByFairness (Emi ,Em2 ,Sh,Sk) , assign(Em2 ,Sh,Sk) , not assign(Emi ,Sh,Sk) . 



Recall that a single day is considered during an execution. 




4-3 Turnover and Fairness Requirements 
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4-4 Crucial Roles 

In order to preserve crucial roles, the assignment of employees qualified for few 
crucial skills has to be preferred. Note that employees having many crucial skills 
may act as "wildcards" and should be employed with parsimony. This aspect is 
encoded by the rule 

prefByCruciaKEmi ,Em2 ,Sh,Sk) :- hasCrucial (Emi ,Ni) , hasCrucial(Em2 ,N2) , 
canBeAssigned(Emi ,Sh,Sk) , canBeAssigned(Em 2 ,Sh,Sk) , Ni < N2 . 

modeling a priority order that depends on the number of crucial skills of employees. 
Finally, assignments not respecting preferences on crucial roles are discarded by the 
following constraint: 

:- prefByCruciaKEmi ,Eni2 ,Sh,Sk) , assign (Em2 ,Sh,Sk) , not assign (Emi ,Sh,Sk) . 

4-5 Double Shifts 

A double shift comprises two simple shifts in which an employee is possibly enrolled 
in different roles (one for each component). However, constraint (*) in Section l4~2l 
prevents to enroll an employee in different roles in a run. Thus, for allowing the 
association of the same employees in a double shift, constraint (*) is modified as 
follows: 

:- assign (Em, Shi ,_) , assigned (Em, SI12 ,_) , Shi 7^ SI12 , not isDouble(Shi ,Sh2) . 

Moreover, recall that an instance of isDouble(Sh sm(1 ;; ,Shw g ) is in the input whenever 
Sh. sma u and Sh Mg constitute a double shift, and the number of employees required by 
Shsmaii is less than or equal to the one required by Sh M9 . Thus, the rules 

:- isDouble(Sh sma n ,Sh M g) , assigned(Em,Sh sma ;/) , not assigned(Em,Sh Mg ) . 

assigned(Em,Sh) :- assign (Em, Sh, _) . 

enforce that all employees assigned to Sh smoii must be assigned to Sh big as well. 
Finally, for respecting bounds on weekly, daily, and overtime working hours, the 
following constraints are added: 

:- isDouble(Shi ,Sh2) , as signed (Em, Shi ) , assigned (Em, Sh2 ) 
shift (Shi ,Di) , shift (Sh 2 ,D 2 ) , workedWeeklyHours (Em.Wh) , 
weekHours (Hmax) , Wh + Di + D2 > Hmax. 

:- isDouble(Shi ,Sh2) , assigned(Em,Shi) , assigned (Em, Sh2 ) 
shift (Shi ,Di) , shift (Sh 2 ,D 2 ) , workedDailyHours(Em,Wh) , 
weekHours (Hmax) , Wh + Di + D2 > Hmax. 

:- isDouble(Shi ,Sh2) , as signed (Em, Shi ) , assigned (Em, Sh2 ) 

shift (Shi ,Di) , shift (Sh2 ,D2) , workedWeekOvertimeHours (Em,Wh) , 
weekHours (Hmax) , Wh + Di + D2 > Hmax. 

In particular, these constraints discard assignments in which an employee violates 
time constraints when enrolled in both components of a double shift. 
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4-6 Dealing with Inconsistency 

The ASP program described so far provides admissible solutions of the team build- 
ing problem where all the requirements are satisfied. It is easy to see that the 
combined action of different constraints may cause situations where there is no 
admissible solution. As an example, suppose we want to compose a team of two 
people covering two different roles, where skill s± and S2 are required. Suppose also 
that si is a skill subject to turnover, and e\ is the only employee that can be as- 
signed to si for respecting this requirement; moreover, all the employees but e\ 
have worked for 20 hours so far, while e\ has just worked for 10 hours (note that 
such a situation is not unusual, because e\ may have worked during night in its last 
assignment). According to the fairness requirement, no one should be preferred to 
e\ for covering s-i. This leads to a conflicting scenario where e\ is the only possible 
choice for both s\ and S2, but the same employee cannot cover two distinct roles 
in the same team. Similar conflicting situations can occur in more complex settings 
where similar "loops" might happen. 

Note that, in a real world scenario, it is often the case that all the constraints 
cannot be simultaneously satisfied. In order to deal with such a problem, together 
with ICO BLG managers, we devised a strategy applying constraints in a prioritized 
way. In particular, the managers of the company specified that the constraints 
have to be applied in the following importance order: (1) turnover, (2) fairness, 
and (3) crucial roles conditions (where the application of the leftmost has higher 
precedence). The idea is to avoid the application of more than one constraint on 
the same pair of employees. For instance, if an employee Emi is preferred to Em2 
according to the turnover, then fairness and crucial roles preferences must not be 
applied on the same workers. Thus, even if Em2 would be preferable to Emi because of 
the fairness constraint, still Emi should be possibly taken. In order to implement this 
specification, we devised a prioritized variant of the above-mentioned constraints: 

:- prefByCruciaKEmi ,Eni2 ,Sh,Sk) , assign (Em2 ,Sh,Sk) , 

not assign(Emi ,Sh,Sk) , not prefByTurnover (Emi .Em2 ,Sh,Sk) , 
not pref ByFairness (Emi , Em2 , Sh , Sk) . 

:- pref ByFairness (Emi ,Em2 ,Sh,Sk) , assign(Em2 ,Sh,Sk) , 

not assign(Emi ,Sh,Sk) , not pref ByTurnover (Emi ,Em2 ,Sh,Sk) . 

The first constraint applies crucial role priority among two employees only if both 
turnover of roles and fairness requirements do not apply on the same employees. In 
a similar way, the second constraint enforces fairness only if the turnover constraint 
does not apply. Note that the constraint implementing turnover requirement did 
not need any reformulation. Indeed, they have the highest priority and, thus, have 
to be applied in any case. 

Within our system, the encoding modified with constraint priority is run auto- 
matically if no answer set is produced by the original encoding. In this way, the 
system can find "acceptable" solutions by ignoring constraints that are in conflict 
with ones of higher priority. The system alerts the user when such a case occurs. 
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Graphic User Interface (GUI) 



Eclipse RCP 



Application Logics 



Java SDK 



DLV 



Fig. 1. System Architecture 



4-7 Team Checking 

Upon an explicit customer request, our system also allows the user to modify a 
computed team (partially or completely). Whenever a team is manually modified, 
the system checks whether it violates some constraints and informs the user. The 
checking is carried out by running the same program above, where the "guessing" 
rule is replaced by a set of facts for the "assign" predicate for specifying the team. 

In case of inconsistency, one might be interested in finding the causes of the 
conflict. To this end, a slightly modified version of the same program can be ex- 
ploited for detecting violated constraints, where specifically conceived atoms are 
introduced in the head of the constraints modeling preference conditions. For ex- 
ample, the constraint requiring the turnover of heavy /dangerous roles is replaced 
by the following rule: 

violatedTurnover(Emi ,Em2 ,Sh,Sk) :- pref ByTurnover (Emi ,Em2 ,Sh,Sk) , 
assign(Em2 ,Sh,Sk) , not assign(Emi ,Sh,Sk) . 

An instance of violatedTurnover (Emi ,Em 2 ,Sh,Sk) is derived whenever employees Emi 
and Em 2 violate the turnover constraint for shift Sh and skill Sk. Clearly, analogous 
modifications can be applied to all the problem constraints. In this way, suitable 
explanation of violations can be provided so that the user can take corrective ac- 
tions. 



5 System Architecture and Usage 

The architecture of the team-building system is depicted in Figure [TJ The system 
integrates the ASP system DLV (jLeone et al. 2006|) and features a Graphical User 
Interface (GUI) developed in Java. In particular, the GUI is based on the Rich 
Client Platform (RCP) technology exploiting an application logics (also developed 
in Java) which embeds OntoDLV (|Ricca et al. 2009f (an ontology management and 
reasoning system based on DLV) for implementing both the reasoning services and 
data-storage features. 

The GUI combines in a single customizable frame all the controls (see Figure [2]) . 
In particular, a tree-shaped calendar (displayed on the left) allows for browsing and 
scheduling working activities. Meta-plans specifications, usually identified by the 
name of the handled cargo boats (e.g., Velasquez, Autoroute), are the leaves of the 
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tree; they can be added or removed by right-clicking on their name and selecting 
the proper command from a context-menu. Meta-plans information (ship arrival 
and departure date, available processing time and requested skills) is displayed in 
and editable through the "Logistics" panel. Below, the "Inclusion" and "Exclusion" 
panels allow pre-assigning (or excluding) specific employees from the team. To run 
the team builder engine, the user select a meta-plan (from the tree) and chooses the 
"run" item from a context- menu (activated by right-clicking the selection) [f| Once 
a meta-plan is run, input information and personnel statistics are fed into the DLV 
system and the result is displayed on the top-right panel ("Team Properties"). The 
computed team can be also modified manually, and the system is able to verify if 
the manually-modified team still satisfies the constraints. In case of errors, causes 
are outlined and suggestions for fixing a problem proposed. The interface gives 
full control on the status of all the seaport-staff: available/unavailable personnel is 
listed on the bottom-right panel, and the allocation statistics are reported in the 
bottom panel. 



6 Some Experiments on Real-world Data 

To provide a concrete image on the behavior of the system, we report on a use 
case performed on real-world data. In particular, we have simulated the employee- 
allocation on archive data provided by ICO BLG, regarding 130 employees and the 
activity of one month. We condidered four allocation activities: (n) one shift, (rz) a 
daily allocation, (r%) a weekly allocation, and (r^) a monthly allocation. The system 
was installed in the ICO BLG workstation featuring an Intel Core 2 Duo CPU P8600 
machine clocked at 2.40 GHz with 4 GB of RAM running Microsoft Windows XP 
and Java version 1.6.0_14. The runtime for accomplishing the simulation of (ri), 
( r 2), (fs) an d (r<s) was: 4.2 seconds, 25.3 seconds, 128.7 seconds, and 490.6 seconds, 
respectively Basically, in a few seconds the system is able to generate a shift plan, 
and in some minutes one can simulate a complete allocation covering an entire 
month (this feature can be used for estimating both long-range and mid-range 
employees allocation needs). 

In order to assess the quality of the obtained plans, we compared the results of our 
system with the manually-prepared solution provided by the ICO BLG managers. 
The results confirm the higher quality of the solutions provided by our system; 
indeed, the number of constraints violations results dramatically reduced when 
the system-produced allocations are compared with hand-made ones. Further, the 
solutions provided by the system would have caused a decrease of about 20% in the 
amount of overtime needed. Those results confirmed the practical effectiveness of 
the ASP-bascd approach, and definitely convinced the ICO BLG management to 
adopt our system for workforce management. 



Note that multiple meta-plans can be executed by selecting several items from the tree. 
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Fig. 2. The Team-builder Graphic User Interface 
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7 Conclusion 

In this paper we have presented a team building system based on Answer Set Pro- 
gramming. The system features a graphical user interface that gives full control on 
the status of the seaport-staff and allows for transparently running the DLV system 
for computing, checking and completing suitable teams of employees respecting the 
given constraints. The system has been developed side by side with the personnel 
of ICO BLG and is currently employed by the management staff of that company. 
The practical effectiveness of the proposed solution is confirmed by the on-the-field 
usage impressions reported by the ICO BLG management members: "the system is 
able to obtain more reliable results when compared to manual team composition, 
and its use reduced the time spent for team building by several hours each month." 
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